Systems and methods for phone number certification and verification

ABSTRACT

Methods, systems, apparatuses, and computer-readable storage mediums are described for issuing digital certificates to phone numbers and verifying phone numbers based on the digital certificates. For instance, a client may request from a certificate authority a digital certificate to be associated with the client&#39;s phone number. The certificate authority issues a phone number challenge to the client to verify that the request did in fact come from the client. The certificate authority signs and issues the digital certificate to the client responsive to a successful challenge. The digital certificates are utilized to exchange messages between a caller and call recipient to determine whether a phone number provided via CLI is accurate or inaccurate. Embodiments described herein determine whether the phone number is accurate using a process referred herein as positive CLI verification and determines whether the phone number is inaccurate using a process referred herein as negative CLI verification.

BACKGROUND

Digital certificates are powerful tools in cybersecurity, but currentlyrequire an issuance process which could be improved for someapplications. Digital certificates are generally issued to an identifiedentity (e.g. a company, a website, a person, etc.). The CertificateAuthority (CA) must perform some identity verification process, which isa difficult logistical problem. The certificate also contains the nameof the entity, which identifies the user. This creates a privacy concernfor individuals who wish to retain some level of anonymity. Certificatescan be issued to a pseudonym, but a different problem arises. If adigital certificate is issued to an individual under a pseudonym, howdoes another user find the certificate? Unless the other userspecifically knows the pseudonym used to register for the certificate itwill be difficult to find the proper certificate.

Calling Line Identification (“CLI”, also known as “Caller ID”)“spoofing” is the act of modifying outgoing CLI on a telephone call. CLIspoofing has become a significant problem in the United States.Robocalls, spam calls, and scam calls are frequently made using spoofedCLI. The spoofed CLI makes holding malicious callers accountabledifficult. By some estimates, these calls may make up to 25% of alltelephone calls in the United States each year, with telephone scams andfrauds costing Americans almost $10 billion annually. In this contextCLI spoofing is clearly an issue, but CLI spoofing has legitimate usesas well. For example, companies frequently spoof the CLI of outgoingcalls to show the company's mainline number, not the calling employee'sspecific line or extension.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

Methods, systems, apparatuses, and computer-readable storage mediums aredescribed for issuing digital certificates to phone numbers andverifying phone numbers based on the digital certificates. For instance,a client may request from a certificate authority a digital certificateto be associated with the client's phone number. The certificateauthority issues a phone number challenge to the client to verify thatthe request did in fact come from the client. The certificate authoritysigns and issues the digital certificate to the client responsive to asuccessful challenge. The digital certificates are utilized to exchangemessages between a caller and call recipient to perform variousoperations, including, but not limited to, determining whether a phonenumber provided via CLI is accurate or inaccurate.

In a further aspect, the phone number is determined to be accurate usinga process referred herein as positive CLI verification and determineswhether the phone number is inaccurate using a process referred hereinas negative CLI verification. When performing positive CLI verification,the caller's client sends a message, comprising his phone number andsigned with his digital certificate, to the call recipient. Uponreceiving the phone call, the call recipient's client compares the phonenumber extracted from the CLI and the phone number in the message. Ifthe phone numbers match, the call recipient's client determines that thephone number included in the CLI is accurate. If the phone numbers donot match (or if no message is received from the caller), the callrecipient's client switches to negative CLI verification. Whenperforming negative CLI verification, the call recipient's clientdetermines whether the phone number included in the CLI is associatedwith a digital certificate and, if so, sends a message to thecertificate holder to verify that the certificate holder did not justmake the telephone call. If the certificate holder confirms that no suchcall was made, then the call recipient determines that the incoming CLIis not accurate.

Further features and advantages of embodiments, as well as the structureand operation of various embodiments, are described in detail below withreference to the accompanying drawings. It is noted that the methods andsystems are not limited to the specific embodiments described herein.Such embodiments are presented herein for illustrative purposes only.Additional embodiments will be apparent to persons skilled in therelevant art(s) based on the teachings contained herein.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate embodiments of the present applicationand, together with the description, further serve to explain theprinciples of the embodiments and to enable a person skilled in thepertinent art to make and use the embodiments.

FIG. 1 shows a block diagram of a system for issuing a signed digitalcertificate for a phone number in accordance with an example embodiment.

FIG. 2 shows a block diagram of another system for issuing a signeddigital certificate for a phone number in accordance with anotherexample embodiment.

FIG. 3 shows a flowchart of a method for associating a signed digitalcertificate with a phone number associated with a client in accordancewith an example embodiment.

FIG. 4 is a block diagram of a system for performing positive callingline identification verification in accordance with an exampleembodiment.

FIG. 5 shows a flowchart of a method implemented by a client associatedwith a call recipient for verifying a phone number included in incomingcalling line identification in accordance with an example embodiment.

FIG. 6 is a block diagram of a system for verifying a phone numberincluded in incoming calling line identification in accordance with anexample embodiment.

FIG. 7 is a block diagram of a system for performing negative callingline identification verification in accordance with an exampleembodiment.

FIG. 8 shows a flowchart of a method implemented by a client associatedwith a call recipient for determining whether a phone number included inan incoming calling line identification is inaccurate in accordance withan example embodiment.

FIG. 9 is a block diagram of a system for determining whether a phonenumber included in an incoming calling line identification is inaccuratein accordance with an example embodiment.

FIG. 10 is a block diagram of an exemplary mobile device in whichembodiments may be implemented.

FIG. 11 is a block diagram of an example processor-based computer systemthat may be used to implement various embodiments.

The features and advantages of the embodiments described herein willbecome more apparent from the detailed description set forth below whentaken in conjunction with the drawings, in which like referencecharacters identify corresponding elements throughout. In the drawings,like reference numbers generally indicate identical, functionallysimilar, and/or structurally similar elements. The drawing in which anelement first appears is indicated by the leftmost digit(s) in thecorresponding reference number.

DETAILED DESCRIPTION I. Introduction

The following detailed description discloses numerous exampleembodiments. The scope of the present patent application is not limitedto the disclosed embodiments, but also encompasses combinations of thedisclosed embodiments, as well as modifications to the disclosedembodiments.

References in the specification to “one embodiment,” “an embodiment,”“an example embodiment,” etc., indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to effect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

In the discussion, unless otherwise stated, adjectives such as“substantially” and “about” modifying a condition or relationshipcharacteristic of a feature or features of an embodiment of thedisclosure, are understood to mean that the condition or characteristicis defined to within tolerances that are acceptable for operation of theembodiment for an application for which it is intended.

Numerous exemplary embodiments are described as follows. It is notedthat any section/subsection headings provided herein are not intended tobe limiting. Embodiments are described throughout this document, and anytype of embodiment may be included under any section/subsection.Furthermore, embodiments disclosed in any section/subsection may becombined with any other embodiments described in the samesection/subsection and/or a different section/subsection in any manner.

II. Example Embodiments

Phone numbers may belong to a variety of interacting entities such asindividuals, companies, organizations, or government offices. Theidentity of the entity which owns a phone number is not generally publicknowledge. However, a person's phone number is easily shared amongfriends, family, and other associations. For these reasons, phonenumbers would make effective pseudonyms for digital certificates.

The embodiments described herein are directed to issuing digitalcertificates to phone numbers and verifying phone numbers based on thedigital certificates. For instance, a client may request from acertificate authority a digital certificate to be associated with theclient's phone number. The certificate authority issues a phone numberchallenge to the client to verify that the request did in fact come fromthe client. The certificate authority signs and issues the digitalcertificate to the client responsive to a successful challenge. Thedigital certificates are utilized to exchange messages between a callerand call recipient to perform various options, including, but notlimited to, determining whether a phone number provided via CLI isaccurate or inaccurate.

Embodiments described herein determine whether the phone number isaccurate or inaccurate in various ways. For instance, a determinationwhether the phone number is accurate may be made using a processreferred herein as positive CLI verification. A determination whetherthe phone number is inaccurate may be made using a process referredherein as negative CLI verification. For example, when performingpositive CLI verification, the caller's client sends a message,comprising his phone number and signed with his digital certificate, tothe call recipient. Upon receiving the phone call, the call recipient'sclient compares the phone number extracted from the CLI and the phonenumber in the message. If the phone numbers match, the call recipient'sclient determines that the phone number included in the CLI is accurate.If the phone numbers do not match (or if no message is received from thecaller), the call recipient's client switches to negative CLIverification. When performing negative CLI verification, the callrecipient's client determines whether the phone number included in theCLI is associated with a digital certificate and, if so, sends a messageto the certificate holder to verify that the certificate holder did notjust make the telephone call. If the certificate holder confirms that nosuch call was made, then the call recipient determines that the incomingCLI is not accurate.

The issued digital certificates advantageously allow peer-to-peerverification of an association with a phone number. An association mightbe that a person owns the phone number, works for the entity that ownsthe phone number, or is otherwise allowed to use the phone number. Userscan digitally sign data to verify that they hold the certificate, whichin turn verifies their association with the phone number. This createsthe potential for a wide variety of new applications which utilizeidentification on the internet via phone numbers and offers severalbenefits over conventional certification systems.

For example, other certification systems issue certificates to specificdomains, users, servers, or email addresses, but the embodimentsdescribed herein are unique in that IP-domain certificates are issuedfor non-IP domain phone numbers. Embodiments described herein are alsoconfigured such that the phone number is the only piece of identifyinginformation. Other certification systems require all necessaryidentifying information to be included in the certificate information.Embodiments described herein do not require, or even allow, additionalidentifying information such as a personal name or company organization.That is, embodiments described herein do not require that personallyidentifying information be provided by or about the user. Yet, theembodiments described herein still provide important identification andsecurity capabilities. Even though no other identifying information isincluded in the digital certificate, embodiments described herein allowusers to be identified if an identity-phone number mapping is known.This would be the case if one user knew the phone number of a friend, orif a certificate was issued for the main phone line of a large company.The duality of this situation is helpful in some applications. Forinstance, the embodiments described herein are flexible enough toaccommodate legitimate use cases where spoofing may be desired, such asa company which wants to set all outgoing calls to provide the CLI of acentral company line.

Embodiments described herein also provide a lookup service that clientscan use to retrieve certificate information about other clients andrelay servers to send messages to and/or from callers and callrecipients. The relay servers provide a statically addressable URI bywhich clients transmit and receive peer-to-peer messages to each other.The usage of the digital certificates allows clients to performadditional peer-to-peer functions such as verification (via digitalsignatures) and encryption. This improves security and privacy byallowing applications to remove centralized servers from theseprocesses. That is, encryption may be configured for end-to-end use.This means that malicious entities cannot compromise the confidentialityof a message even if the lookup service or relay servers is/arecompromised. Digital signatures also assure message recipients of thesender's identity and of the integrity of the message.

The embodiments described herein also do not require user accounts.Because the only piece of unique information is the phone number, whichis verified during the phone number challenge, users do not needaccounts to manage their certificates. This means that users do notspecifically need to keep track of usernames or passwords to use systemswhich rely on digital certificates or the systems described herein. If amalicious entity compromises the system, no username or password datawill be exposed.

Such embodiments are described in further detail as follows. SubsectionA describes embodiments directed to issuing signed digital certificatesfor phone numbers. Subsection B describes embodiments directed toperforming phone number verification.

A. Techniques for Issuing Signed Digital Certificates for Phone Numbers

FIG. 1 shows a block diagram of a system 100 for issuing a signeddigital certificate for a phone number in accordance with an exampleembodiment. As shown in FIG. 1, system 100 includes a certificateauthority 102, a lookup service 104, a relay server 138 and a pluralityof clients 106A-106C. Each of clients 106A-106C are communicativelycoupled to certificate authority 102 via first communications network108 and a second communications network 110. Clients 106A-106C,certificate authority 102, lookup service 104, and relay server 138 arecommunicatively coupled via second communications network 110. Firstcommunication network 108 may comprise one or more networks, such as,but not limited to, a landline network (e.g., a public switchedtelephone network), a cellular or mobile network, and/or any networkthat enables communication with a client device (e.g., clients106A-106C) via a telephone number assigned thereto. Secondcommunications network 110 may comprise one or more networks such aslocal area networks (LANs), wide area networks (WANs), enterprisenetworks, the Internet, etc., and may include one or more of wiredand/or wireless portions.

Client 106A may comprise an enterprise or other business entity. Client106A comprises a server 112 and a plurality of telephone devices120A-120C coupled thereto. Server 112 and telephone devices 120A-120Cmay be included as part of a private branch eXchange (PBX) telephonesystem that accommodates multiple incoming phone calls to a common phonenumber that are routed to different telephone devices of telephonedevices 120A-120C. For instance, server 112 may comprise switching logicconfigured to receive incoming phone calls and route the calls todifferent ones of telephone devices 120A-120C. Server 112 iscommunicatively coupled to communications network 108 and/orcommunications network 110. Server 112 may be communicatively coupled tocommunications network 108 via a RJ11 cable or any interface suitablefor coupling server 112 to a landline network. Server 112 may becommunicatively coupled to communications network 110 via an Ethernetinterface or WiFi interface, although these are only examples. Telephonedevices 120A-120C may be similarly coupled to server 112 via a RJ11cable, although the embodiments described herein are not so limited.

In an embodiment, the PBX may be implemented as a Voice over InternetProtocol (VoIP)-based PBX. In accordance with such an embodiment, server112 is configured to receive telephony services via a VoIP connection.The VoIP connection may be implemented, for example, over a broadbanddata service such as Digital Subscriber Line (DSL), Integrated ServicesDigital Network (IDSN), data over cable, T1/T3, optical carrier,carrier-class Ethernet, satellite or any other suitable data service.The various physical transport media used for implementing such dataservices are well known. In one embodiment, server 112 connects to theappropriate data service via an Ethernet interface or WiFi interface,although these are only examples. Similarly, each of telephone devices120A-120C may be coupled to server 112 via an Ethernet interface or WiFiinterface.

Client 106B may comprise a telephone device 118 and a phone numbercertification (PNC) device 116. PNC device 116 is configured to becoupled to communications network 108 and/or communications network 110.PNC device 116 may be communicatively coupled to communications network108 via a RJ11 cable or any interface suitable for coupling PNC device116 to a landline network. PNC device 116 may be communicatively coupledto communications network 110 via an Ethernet interface or WiFiinterface, although these are only examples. Telephone device 118 may besimilarly coupled to standalone device via a RJ11 cable.

In accordance with an embodiment, client 106B is configured to receivetelephony services via a VoIP connection. In one embodiment, PNC device116 and/or telephone device 118 connects to the appropriate data servicemade available through communications network 110 via an Ethernetinterface or WiFi interface, although these are only examples.Similarly, telephone device 118 may be coupled to PNC device 116 via anEthernet interface or WiFi interface.

Client 106C may comprise a smart phone communicatively coupled tocommunications network 108 and communications network 110. Client 106Cis coupled to communications network 108 and communications network 110via one or more wireless modems. The modem(s) can include a cellularmodem for communicating with the mobile communication network (e.g.,communications network 108) and/or other radio-based modems forcommunicating via other wireless networks, such as communicationsnetwork 110. The cellular modem may be configured to enable phone calls(and optionally transmit data) according to any suitable communicationstandard or technology, such as GSM (Global System for MobileCommunications), 3G (third-generation), 4G (fourth-generation), 5G(fifth-generation), etc. At least one of the wireless modem(s) istypically configured for communication with one or more cellularnetworks, such as a GSM network for data and voice communications withina single or multiple cellular networks (e.g., communications network108), or between the smart phone and a public switched telephone network(PSTN) (e.g., communications network 110).

As also shown in FIG. 1, server 112, PNC device 116, and smart phone106C comprise a PNC application 114. PNC application 114 is configuredto provide an initial request for a signed digital certificate tocertificate authority 102. The request may comprise a public keyassociated with the phone number of the client from which the requestoriginates (e.g., clients 106A-106C) and the phone number of the client.The request may further specify a phone number verification process tobe utilized to verify that the initial request originated from the ownerof the client. The request is provided via communications network 110.It is noted that a client may be associated with a plurality ofdifferent phone numbers. In such a case, the client may request a signeddigital certificate for each of the phone numbers. For instance, theclient may issue an initial request for each phone number, where therequest includes a particular public key associated with a particularphone number associated with the client, the phone number, and/or phonenumber verification process. Alternatively, the client may issue asingle initial request comprising the plurality of public keys, phonenumbers and/or phone number verification processes.

Certificate authority 102 is configured to issue a phone numberchallenge in accordance with the phone number verification process, forexample, specified by a particular received request. For instance,certificate authority 102 may provide a phone number verificationrequest that specifies a verification code. The phone numberverification request is provided to the requesting client viacommunications network 108. Upon receiving the verification code, theuser may enter the code via PNC application 114. For instance, PNCapplication 114 may comprise a user interface configured to receive userinput. The user may provide the verification code as user input usingthe user interface. Responsive to receiving the verification code, PNCapplication 114 provides the verification code to certificate authority102 via a response. The response is provided to certificate authority102 via communications network 110.

Certificate authority 102 is configured to verify if the receivedverification code matches the verification code provided to therequesting client. If the code matches, then certificate authority 102determines that the initial request originated from the owner of thephone number specified by the initial request and generates and signsthe certificate with a digital signature. The certificate comprises thephone number of the requesting client for which the certificate wasgenerated and the public key associated with that phone number.Certificate authority 102 provides the signed digital certificate to therequesting client via communications network 110. Certificate authority102 also provides the signed digital certificate to lookup service 104.

If the code does not match, then certificate authority 102 determinesthat the initial request did not originate from the owner of the phonenumber specified by the initial request and does not generate thecertificate.

Lookup service 104 stores the signed digital certificate(s) in datastorage maintained thereby. Lookup service 104 maintains an associationbetween the signed digital certificate(s) and the respective phonenumbers for which the signed certificate(s) were issued. Lookup service104 enables the signed digital certificate(s) to be made available(e.g., looked up) by requesting entities. For instance, a requestingentity may provide a request for a digital certificate. The request mayspecify a phone number. Lookup service 104 determines whether itmaintains a digital certificate that is associated with the specifiedphone number. Responsive to determining that such a digital certificateis maintained thereby, lookup service 104 provides the digitalcertificate to the requesting entity.

Certificate authority 102 also registers the requesting client withrelay server 138. For instance, certificate authority 102 may send arequest to relay server 138 via communications network 110. Responsiveto receiving the request, relay server 138 may allocate a static (orstatically-addressable) uniform resource identifier (URI) for therequesting client. The statically-addressable URI may be an Internetprotocol (IP) address. Relay server 138 may provide a response tocertificate authority 102 that indicates that a URI has been allocatedfor the requesting client. Certificate authority 102 may provide theURI, along with the signed digital certificate, to lookup service 104.Alternatively, relay server 138 may provide the URI directly to lookupservice 104. It is noted that any number of relay servers may beutilized for any number of clients.

In accordance with an embodiment, the initial request provided by therequesting client specifies the URI of relay server 138, and certificateauthority 102 may provide the URI to lookup service 204. In accordancewith another embodiment, responsive to receiving the initial requestcomprising the URI, certificate authority 102 may send a request torelay server 138 comprising the URI to verify and/or allocate the URI.Relay server 138 allocates the specified URI and sends a response tocertificate authority 102 accordingly.

When generating the digital certificate, certificate authority 102 mayalso include the URI of relay server 238 in the digital certificate.

It is noted that each of certificate authority 102 and lookup service104 may be implemented via a computing device, such a server. Inaccordance with an embodiment, certificate authority 102 and lookupservice 104 are implemented by the same server. In accordance withanother embodiment, certificate authority 102 and lookup service 104 areimplemented in different servers. In accordance with yet anotherembodiment, certificate authority 102 and/or lookup service 104 areimplemented in relay server 138. It is further noted that while FIG. 1shows three clients 106A-106C and three telephone devices 120A-120C forclient 106A, system 100 may comprise any number of clients and telephonedevices for client 106A.

It is further noted that while FIG. 1 depicts each of clients 106A-106Ccomprising PNC application 114, each of clients 106A-106C may compriseits own version of PNC application 114. For instance, PNC application114 of client 106A may be configured for execution on server 112, PNCapplication 114 of client 106B may be configured for execution on PNCdevice 116, and PNC application 114 of client 106C may be configured forexecution on smart phone 106C.

FIG. 2 shows a block diagram of a system 200 for issuing a signeddigital certificate for a phone number in accordance with anotherexample embodiment. As shown in FIG. 2, system 200 comprises acertificate authority 202, a lookup service 204, a relay server 238, aPNC application 214, and a client 206. Certificate authority 202 iscommunicatively coupled to client 206 via communications network 208and/or communications network 210. Client 206, certificate authority202, lookup service 204, and/or relay server 238 are communicativelycoupled via communications network 210. Certificate authority 202 is anexample of certificate authority 102, lookup service 204 is an exampleof lookup service 104, relay server 238 is an example of relay server138, client 206 is an example of any of clients 106A-106C,communications network 208 is an example of communications network 108,and communications network 210 is an example of communications network110, as respectively described above with reference to FIG. 1.

Client 206 comprises a telephonic device 216 (e.g., telephones120A-120C, telephone 118, smart phone 106C, as described above withreference to FIG. 1) and PNC application 214. PNC application 214 may beincorporated in telephonic device 216, for example, in an embodiment inwhich telephonic device 216 is a smart phone. Alternatively, PNCapplication 214 is incorporated in a device other than telephonic device216. For instance, PNC application 214 may be incorporated in a device(e.g., PNC device 116 or server 112, as shown in FIG. 1) communicativelycoupled to telephone device 216.

Certificate authority 202 comprises a code issuer 218, a certificatesigner 220, and a request receiver 222. PNC application 214 comprises akey generator 224, a request sender 226, and a user interface 230. PNCapplication 214 also maintains one or more capabilities 228 that aresupported by telephonic device 216 and/or characteristics thereof. Forinstance, capabilities 228 may comprise an identifier of a phone numberverification process supported by telephonic device 216. Capabilities228 may also comprise the phone number associated with telephonic device216. Capabilities 228 may be determined via an automated discoveryprocess between PNC application 214 and telephonic device 216.Alternatively, capabilities 228 may be user-specified.

Key generator 224 is configured to generate a private/public key pair.Key generator 224 may be configured to generate a private/public keypair for each phone number associated with client 206. Key generator 224may generate the private/public key pair(s) in accordance with anytechnique known in the art, including, but not limited to, aRivest-Shamir-Adleman (RSA) encryption-based techniques, ElGamalencryption-based techniques, Digital Signature Standard (DSS)encryption-based techniques, etc. PNC application 214 stores the privatekey locally on the device on which PNC application 214 executes. Thepublic key(s) (shown as public key(s) 232) and/or private key(s) areprovided to request sender 226.

Request sender 226 is configured to receive public key(s) 232 andretrieve capabilities and/or characteristics of telephonic device 216,such as the identifier of the phone number verification process(es)supported by telephonic device 216 and phone number(s) associated withtelephonic device 216. Request sender 226 generates an initial request234 for a signed digital certificate for a particular phone numberassociated with client 206 and provides initial request 234 tocertificate authority 202 via communications network 210. In accordancewith an embodiment, request sender 226 may encrypt or sign initialrequest 234 utilizing the private key associated with the phone number.Initial request 234 comprises the public key(s) and the phone number(s)associated with telephonic device 216. In accordance with an embodiment,initial request 234 may further comprise the phone number verificationprocess identifier(s). In accordance with another embodiment, initialrequest 234 comprises a URI of relay server 238. In accordance withanother embodiment, the phone number verification process identifier(s)and/or URI of relay server 238 are not included in initial request 234and is provided separately to certificate authority 202, e.g., viaanother request.

In accordance with an embodiment in which PNC application 214 executeson a server (e.g., server 112) or a PNC device (PNC device 116), request234 may be provided via an Ethernet interface, WiFi interface, and/orthe like of such devices. In accordance with an embodiment PNCapplication 214 executes on smart phone (e.g., client 106C), request 234may be provided via a wireless modem of the smart phone.

Request receiver 222 of certificate authority 202 is configured toreceive request 234 via communications network 210, for example, via awired or wireless network interface. In accordance with an embodiment,request receiver 222 analyzes initial request 234 to determine therequest sender's phone number(s), phone number verification processidentifier(s), and/or the URI of relay server 238. In accordance withanother embodiment, request 234 may not specify the phone numberverification process, and request receiver 222 infers the phone numberverification process based on how request 234 is received. For instance,certificate authority 202 may be configured to receive requests fromclient 206 via different URIs associated with certificate authority 202,where each URI is mapped to a different phone number verificationprocess. Accordingly, if a request from client 206 is received via afirst URI, request receiver 222 determines that the phone numberverification process is the process associated with the first URI.Similarly, if a request from client 206 is received via a second URI,request receiver 222 determines that the phone number verificationprocess is the process associated with the second URI.

Request receiver 222 provides the determined phone number(s) and phonenumber verification process identifier(s) to code issuer 218. Codeissuer 218 is configured to issue a phone number verification challengeto the determined phone number(s) in accordance with the phone numberverification process(es) identified by the indicator.

The aim of the phone number verification challenge is to confirm thatthe received initial request 234 originates from the owner of the phonenumber(s). If certificate authority 202 is able to send data to a clientassociated with the phone number(s) and receives the same data back fromthe client requesting the signed certificate, then it is confirmed thatthe phone number(s) are used by that client and initial request 234 isvalid.

The phone number verification process identifier(s) specify a particularphone number verification process from a plurality of phone numberverification processes that is supported by client 206. Examples ofphone number verification processes include, but are not limited to ashort message service (SMS)-based verification process, an audiocode-based verification process, or an automated audio code-basedverification process.

When using an SMS-based verification process, code issuer 218 provides arequest 236 comprising a SMS-based text message to telephonic device216. The SMS-based text message comprises a code (e.g., a numeric oralphanumeric code) to the phone number associated with telephonic device216 via communications network 208. Such a verification process issuitable in embodiments in which client 206 comprises a smart phonecapable of receiving SMS text messages. In accordance with suchembodiments, responsive to receiving the code, the user of client 206inputs the code via user interface 230. User interface 230 may comprisea graphical user interface that enables the user to enter the receivedcode. In accordance with another embodiment, PNC application 214accesses the SMS text messages of client 206 automatically to retrievethe code without user input. PNC application 214 provides a phone numberverification response 240 comprising the received code to certificateauthority 202 via communications network 210. It is noted that the PNCapplication 214 may include the public key in response 240 in additionto or in lieu of providing public key in initial request 234.

When using an audio code-based verification process, code issuer 218places a telephone call to telephonic device 216 via communicationsnetwork 208 in accordance with the phone number received from PNCapplication 214. When the user accepts the phone call, code issuer 218provides (e.g., plays back) a human-comprehensible audio code during thephone call. Such a verification process is suitable in embodiments inwhich client 206 comprises a landline phone (as shown via client 106B inFIG. 1) or a smart phone (as shown via client 106C in FIG. 1). Inaccordance with such embodiments, responsive to hearing the code, theuser of client 206 inputs the code via user interface 230. In accordancewith an embodiment in which telephonic device 216 is a landline phonecoupled to a PNC device (e.g., PNC device 116), user interface 230 maycomprise one or more physical buttons and/or a graphical user interfacethat enables the user to enter the received code. The PNC device mayfurther comprise a display screen configured to display the code enteredin by the user. PNC application 214 provides response 240 comprising thereceived code to certificate authority 202 via communications network210.

When using an automated audio code-based verification process, codeissuer 218 places a telephone call to telephonic device 216 viacommunications network 208 in accordance with the phone number receivedfrom PNC application 214. Such a verification process is suitable inembodiments in which client 206 comprises an enterprise or businessentity (as shown via client 106A in FIG. 1) that utilizes an enterpriseor PBX telephone system in which the telephone system is heavilyautomated, but unable to receive SMS messages. In accordance with suchembodiments, server 112 accepts the phone call, and code issuer 218provides (e.g., plays back) a machine-comprehensible audio code (e.g., adual tone multi frequency (DTMF)-based code) during the phone call. PNCapplication 214 (executing on server 112) receives the phone call,determines the machine-comprehensible audio code, and provides response240 comprising the determined code to certificate authority 202 viacommunications network 210.

Code issuer 218 is configured to receive response 240 and verify if thereceived verification code matches the verification code provided toclient 206. If the code matches, then code issuer 218 determines thatinitial request 234 originated from the owner of the phone numberspecified by initial request 234 and provides an indication tocertificate signer 220 to generate and sign the certificate with adigital signature.

Certificate signer 220 generates and signs the digital certificate andprovides a response 242 comprising the signed digital certificate toclient 206 via communications network 210. The signed digitalcertificate comprises the public key and the phone number specified byinitial request 234. Certificate signer 220 also provides the signeddigital certificate to lookup service 204 via communications network210. In an embodiment in which client 206 comprises an enterprise orbusiness entity (as shown via client 106A in FIG. 1), the signed digitalcertificate is stored in data storage maintained by server 112. Inaccordance with such an embodiment, each telephone device coupled toserver 112 (e.g., telephones 120A-120C may share the same signed digitalcertificate, although the embodiments described herein are not solimited. In an embodiment in which client 206 comprises a landline phone(as shown via client 106B in FIG. 1), the private key generated by keygenerator 224 and the signed digital certificate are stored in datastorage maintained by PNC device 116. In an embodiment in which client206 comprises a smart phone (as shown via client 106C in FIG. 1), theprivate key generated by key generator 224 and the signed digitalcertificate are stored in data storage maintained by the smart phone.

Certificate signer 220 may also register client 206 with relay server238. For instance, certificate signer 220 may send a request 244 torelay server 238 via communications network 210. Responsive to receivingrequest 244, relay server 238 may allocate a statically-addressableuniform resource identifier (URI) for client 206. Thestatically-addressable URI may be an Internet protocol (IP) address.Relay server 238 may provide a response 246 to certificate signer 220that indicates that a URI has been allocated for client 206. Certificatesigner 220 may provide the URI, along with the signed digitalcertificate, to lookup service 204. Alternatively, relay server 238 mayprovide the URI directly to lookup service 204. It is noted that anynumber of relay servers may be utilized for any number of clients. Thatis, clients may be distributed across a plurality of different relayservers. Thus, any downtime associated with a particular relay server(e.g., due to a malicious attack) would only affect the clientsassociated with that server, whereas clients associated with other relayservers that were not attacked would not be affected.

In accordance with an embodiment, initial request 234 provided by PNCapplication 214 client specifies the URI of relay server 238, andcertificate authority 202 may provide the URI to lookup service 204. Inaccordance with another embodiment, responsive to receiving initialrequest 234 comprising the URI, certificate authority 202 may send arequest to relay server 238 comprising the URI to verify and/or allocatethe URI. Relay server 238 allocates the specified URI and sends aresponse to certificate authority 202 accordingly.

When generating the digital certificate, certificate signer 220 may alsoinclude the URI of relay server 238 in the digital certificate.

If the code does not match, then code issuer 218 determines that initialrequest 234 did not originate from the owner of the phone numberspecified by initial request 234 and does not generate the digitalcertificate.

Lookup service 204 is configured to store signed digital certificatesassociated with different phone numbers. The signed digital certificatesare stored in a data storage maintained thereby. Lookup service 204maintains an association between each signed digital certificate, thephone number for which the signed certificate was issued, and the URIallocated therefor. The association may be maintained via a datastructure 248, such, but not limited to, a table. Lookup service 204enables the signed digital certificate and the URI to be made available(e.g., looked up) by requesting entities. For instance, a requestingentity may provide a request for a digital certificate and/or the URIfor a particular phone number. The request may specify the phone number.Lookup service 204 determines whether it maintains a digital certificateand/or URI that is associated with the specified phone number.Responsive to determining that such a digital certificate and/or URI ismaintained thereby, lookup service 204 provides the digital certificateand/or URI to the requesting entity.

Accordingly, a signed digital certificate may be associated with a phonenumber in many ways. For example, FIG. 3 shows a flowchart 300 of amethod for associating a signed digital certificate with a phone numberwith a client in accordance with an example embodiment. In anembodiment, flowchart 300 may be implemented by system 200, as describedin FIG. 2. Accordingly, flowchart 300 will be described with continuedreference FIG. 2. Other structural and operational embodiments will beapparent to persons skilled in the relevant art(s) based on thefollowing discussion regarding flowchart 300 and system 200.

As shown in FIG. 3, the method of flowchart 300 begins at step 302. Atstep 302, a request is received from a client for a signed digitalcertificate, the request specifying the phone number associated with theclient. For example, with reference to FIG. 2, request receiver 222 ofcertificate authority 202 receives a request 234 for a signed digitalcertificate from request sender 226 of PNC application 214. Request 234specifies the phone number associated with telephonic device 216 ofclient 206.

At step 304, a phone number verification process from a plurality ofphone number verification processes is determined based on the request.For example, with reference to FIG. 2, request receiver 222 ofcertificate authority 202 determines a phone number verification processfrom a plurality of phone number verification processes based on request234.

In accordance with one or more embodiments, the request furtherspecifies the phone number verification process. For example, withreference to FIG. 2, request 234 further specifies a phone numberverification process from a plurality of different phone numberverification processes, and request receiver 222 analyzes request 234 todetermine the phone number verification process. In another example,request receiver 222 infers the phone number verification process basedon how request 234 is received. For instance, certificate authority 202may be configured to receive requests from client 206 via different URIsassociated with certificate authority 202, where each URI is mapped to adifferent phone number verification process. Accordingly, if a requestfrom client 206 is received via a first URI, request receiver 222determines that the phone number verification process is the processassociated with the first URI. Similarly, if a request from client 206is received via a second URI, request receiver 222 determines that thephone number verification process is the process associated with thesecond URI.

At step 306, a phone number verification request is provided to theclient in accordance with the determined phone number verificationprocess. The phone number verification request specifies a firstverification code. For example, with reference to FIG. 2, code issuer218 of certificate authority 202 provides a verification request 236 totelephonic device of client 206. Verification request 236 specifies afirst verification code.

At step 308, a determination is made as to whether the secondverification code was received and, if so, whether the secondverification code matches the first verification code. If adetermination is made that the second verification code was not receivedor does not match the first verification code, flow continues to step310. Otherwise, flow continues to step 312.

For example, with reference to FIG. 2, a user, receiving the firstverification code, may enter a second verification code (that matchesthe first verification code) via user interface 230. PNC application 214provides the second verification code to code issuer 218 via response240. Responsive to receiving response 240, code issuer 218 determineswhether the second verification code included in response 240 matchesthe first verification code that was provided via request 236. If nosecond verification code is received, for example, after expiration of apredetermined period of time or if the received second verification doesnot match the first verification code, flow continues to step 310.Otherwise, flow continues to step 312.

In accordance with one or more embodiments, the plurality of differentphone number verification processes comprises an SMS-based verificationprocess. In accordance with such an embodiment, the phone numberverification request is provided as an SMS-based text message thatcomprises the first verification code. The SMS-based text message isprovided via a first communication channel. The second verification codeis received via a second communication channel that is different thanthe first communication channel. For example, with reference to FIG. 2,code issuer 218 issues an SMS-based text message (via request 236)comprising the first verification code to telephonic device 216 viacommunications network 208. PNC application 214 provides the secondverification code to code issuer 218 via communications network 210 (viaresponse 240). For instance, a user, after reading the code, may providethe code via user interface 230, and PNC application 214 provides thecode to code issuer 218.

In accordance with one or more embodiments, the plurality of differentphone number verification processes comprises an audio code-basedverification process. In accordance with such an embodiment, atelephonic communication session is initiated with the client via afirst communication channel. Responsive to the telephonic communicationsession being accepted, the first verification code is provided as anauditory code via the telephonic communication session. The secondverification code is received via a second communication channel that isdifferent than the first communication channel For example, withreference to FIG. 2, code issuer 218 initiates a telephoniccommunication session with telephonic device 216 of client 206 viacommunications network 208. Responsive to the telephonic communicationsession being accepted, code issuer 218 provides (e.g., plays back) anauditory code via the telephonic communication session. PNC application214 provides the second verification code to code issuer 218 viacommunications network 210. For instance, a user, after hearing theauditory code, may provide the code via user interface 230, and PNCapplication 214 provides the code to code issuer 218 via verificationresponse 240.

In accordance with one or more embodiments, the auditory code is inaccordance with a DTMF form. In accordance with such an embodiment, whena server of an enterprise telephone system (e.g., server 112) acceptsthe phone call, code issuer 218 provides (e.g., plays back) amachine-comprehensible auditory code during the phone call. PNCapplication 214 (executing on server 112) determines themachine-comprehensible audio code and provides the code to code issuer218 via verification response 240.

At step 310, the request for the signed digital certificate is denied.For example, with reference to FIG. 2, certificate signer 220 does notgenerate and sign the digital certificate, and request 234 is denied.

At step 312, the signed digital certificate is provided to the client.For example, with reference to FIG. 2, code issuer 218 provides anindication to certificate signer 220 indicating that the secondverification code matches the first verification code. Responsive toreceiving indication, certificate signer 220 generates and signs thedigital certificate and provides the signed digital certificate viaresponse 242.

In accordance with one or more embodiments, in response to determiningthat the second verification code matches the first verification code,the digital certificate is generated, signed and provided to a lookupservice that enables the signed digital certificate to be searchable andretrievable by a plurality of requesting entities. For example, withreference to FIG. 2, certificate signer 220 generates and signs thedigital certificate and provides the signed digital certificate tolookup service 204 via communications network 210. Lookup service 204enables the signed digital signed certificate to be searchable andretrievable by a plurality of requesting entities.

In accordance with one or more embodiments, the signed digitalcertificate comprises at least one of the phone number associated withthe client or a uniform resource identifier associated with a relayserver. For example, with reference to FIG. 2, the signed digitalcertificate comprises at least one of the phone number associated withclient 206 or a uniform resource identifier associated with relay server238.

B. CLI Verification

The embodiments described herein may determine whether a phone numberprovided via calling line identification (CLI) is accurate orinaccurate. Such embodiments determine that the CLI is accurate in aprocess referred herein as positive CLI verification and determine thatthe CLI is inaccurate in a process referred herein as negative CLIverification. In positive CLI verification, the caller sends a messagesigned with its signed digital certificate (as described above withreference to Subsection A) to the call recipient. The message containsinformation that is utilized to confirm that the incoming call isactually associated with the provided CLI. Negative CLI verificationoccurs when no such message was received by the call recipient and asigned digital certificate was issued to the phone number provided inthe CLI. The call recipient sends a message to the certificate holder toverify that the certificate holder did not just make the telephone call.If the certificate holder confirms that no such call was made, then thecall recipient can determine that the incoming CLI is not accurate.

Such embodiments can verify incoming CLI as accurate and determine thatillegitimate phone number spoofing is occurring. It is also flexibleenough to accommodate legitimate use cases where spoofing may bedesired, such as a company which wants to set all outgoing calls toprovide the CLI of a central company line.

Subsection B.1 below describes embodiments directed to positive CLIverification. Subsection B.2 below described embodiments directed tonegative CLI verification.

1. Positive CLI Verification

FIG. 4 is a block diagram of a system 400 for performing positive CLIverification in accordance with an example embodiment. As shown in FIG.4, system 400 includes a call recipient relay server 402, a lookupservice 404, a client 406A, and a client 406B. Clients 406A and 406B areeach an example of clients 106A-106C, as described above with referenceto FIG. 1. Each of clients 406A and 406B comprise a PNC application 414,which is an example of PNC application 114 or PNC application 214, asrespectively described above with reference to FIGS. 1 and 2. Clients406A and 406B are communicatively coupled via a communications network408, which is an example of communications network 108, as describedabove with reference to FIG. 1. Each of clients 406A and 406 are alsocommunicatively coupled to lookup service 404 and call recipient relayserver 402 via a communications network 410, which is an example ofcommunications network 110, as described above with reference to FIG. 1.Lookup service 404 is an example of lookup service 104, as describedabove with reference to FIG. 1. Call recipient relay server 402 is anexample of relay server 138, as described above with reference toFIG. 1. In the example shown in FIG. 4, client 406A represents a callerand client 406B represents a call recipient. Both clients 406A and 406Bhave been issued signed digital certificates, and client 406B has astatically-addressable URI allocated therefor via call recipient relayserver 402.

Positive CLI verification may be initiated when a caller initiates atelephonic communication session via communications network 408 (e.g.,by placing an outgoing phone call, for example, by dialing a phonenumber and/or pressing the ‘Call button, etc.). Upon initiating thetelephonic communication session, PNC application 414 of client 406Aprovides a request 412 to lookup service 404 via communications network410 for the call recipient's (i.e., client 406B) signed digitalcertificate and statically-addressable URI. Request 412 specifies thephone number of the call recipient. Lookup service 404 determines (i.e.,looks up) the signed digital certificate and/or the call recipient'srelay server address that is associated with the phone number andprovides a response 416 via communications network 410. Response 416includes the digital signed certificate and statically-addressable URI.In accordance with an embodiment, the statically-addressable URI isincluded in the signed digital certificate. Client 406A may optionallylocally cache the digital signed certificate and the URI, therebyenabling PNC application 414 to locally retrieve the signed digitalcertificate and the URI without having to query lookup service 404.Client 406A establishes a connection (e.g., an IP-based connection, suchas, but not limited to a transmission control protocol (TCP)-basedconnection, a hypertext transfer protocol (HTTP)-based connection, anopen source remote procedure call-based connection (e.g., gRPC), a userdatagram protocol (UDP)-based connection) with call recipient relayserver 402 using the URI. In accordance with an embodiment, theconnection is a persistent connection. The foregoing operations mayoccur before the phone call is placed to the call recipientAlternatively, the foregoing operations may occur while the phone callis being placed (i.e., while attempting to connect with client 406B).

PNC application 414 of client 406A generates a CLI verification message418 and sends it to call recipient relay server 402 using the URIassociated with client 406B via communications network 410. CLIverification message 418 may be signed using the digital certificate ofclient 406A to indicate that the message 418 is indeed provided byclient 406A. In certain embodiments, such as the embodiment describedabove with reference to client 106A, CLI verification message 418 may besigned using a plurality of digital certificates associated with client406A (for example, signed using a first digital certificate associatedwith an employee's direct line and a second digital certificateassociated with a company's main line). CLI verification message 418 maycomprise the phone number of the caller (i.e., client 406A), the phonenumber of the call recipient (client 406B), the time at which the callwas initiated, and/or a session identifier for the call. CLIverification message 418 may further comprise an online certificatestatus protocol (OCSP) stapled response, which verifies the validitystatus of the signed digital certificate associated with client 406A.PNC application 414 may encrypt CLI verification message 418 (orportions thereof), for example, using the public key of the callrecipient (which is included in the call recipient's signed digitalcertificate retrieved from lookup service 404), before sending CLIverification message 418 to call recipient relay server 402. PNCapplication 414 may leave portions of CLI verification message 418(e.g., the phone number of the call recipient). This enables the callrecipient to determine which private key to use to decrypt CLIverification message 418. Call recipient relay server 402 associates CLIverification message 418 with the phone number of the call recipient andstores CLI verification message 418.

CLI verification message 418 remains encrypted when stored on callrecipient relay server 402, thereby ensuring that only the intended callrecipient is able to read the contents thereof. Thus, even if callrecipient relay server 402 is compromised, the attacker would not beable to extract any of the caller's and call recipient's private data.

When the communication session (i.e., phone call) is received by client406B (but before the user has answered the phone call), PNC application414 of client 406B extracts the phone number from the incoming CLI. Ifclient 406B is already not connected to call recipient relay server 402,PNC application 414 may establish a connection with call recipient relayserver 402, for example, using the statically-addressable URI associatedwith the phone number of client 406B. The connection may be a persistentconnection, thereby enabling call recipient relay server 402 to pushmessages, such as CLI verification messages, to client 406B. In anembodiment in which a persistent connection is not maintained, PNCapplication 414 may provide a request 420 via communications network 410for any messages (e.g., CLI verification message 418) that are beingheld by call recipient relay server 402 and that are directed to client406B. Request 420 comprises the digital signature of client 406Bassociated with client 406B.

Call recipient relay server 402 verifies the identity of the callrecipient based on the digital signature of request 420. If the identityis verified, call recipient relay server 402 provides a response 422 toPNC application 414 of client 406B via communications network 410.Response 422 comprises the CLI verification message(s) (CLI verificationmessage 418) that were being held for client 406B.

PNC application 414 of client 406B decrypts the received message(s),e.g., using the private key associated with client 406B and analyzes themessage(s) to determine the type of message (e.g., whether they areverification messages), whether it is properly signed and to determinethe phone number (included in the message(s)) of the client (i.e.,client 406A) that issued the CLI verification message(s). If the CLIverification message(s) are properly signed, PNC application 414compares the determined phone number to the phone number extracted fromthe incoming CLI. PNC application 414 may also compare the time of thecommunication sessions including in the CLI verification message(s) tothe time at which client 406B receives the incoming phone call. If adetermination is made that the phone numbers match and/or that the timesare within a predetermined threshold (e.g., within 30 seconds) then PNCapplication 414 of client 406B determines that the phone numberspecified by the incoming CLI is accurate (i.e., that the phone numberhas not been spoofed).

It is noted that if the CLI verification message does not include astapled OCSP response and the certificate for the phone numberassociated with the caller, PNC application 414 of client 406B mayretrieve the certificate status information from lookup service 404 orvia one or more certificate revocation lists (CRLs), e.g., obtained fromthe certificate authority (e.g., certificate authority 202, as shown inFIG. 2).

Responsive to determining that the incoming CLI is accurate, PNCapplication 414 of client 406B may cause a notification to be displayedand/or played back indicating the accurate CLI. For instance, PNCapplication 414 cause an indicator (e.g., a checkmark) to be displayedon a display screen of a telephonic device (or PNC device, e.g., PNCdevice 116, as shown in FIG. 1) associated with client 406B. In anotherexample, PNC application may cause a light emitting diode (LED)associated with the telephonic device or PNC device to activated (e.g.,a green LED) that indicates that the incoming CLI is accurate. In yetanother example, PNC application 414 may playback a particular sound orringtone via a speaker of the telephone device and/or PNC device.

If a determination is made that the phone numbers do not match and/orthat the times are not within a predetermined threshold, then PNCapplication 414 of client 406B determines that the phone numberspecified by the incoming CLI may be inaccurate (i.e., that the phonenumber has been spoofed) and performs a negative CLI verificationprocess, which is described below in Subsection B.2. PNC application 414may also determine that the phone number specified by the incoming CLImay be inaccurate and perform a negative CLI verification process ifthere are no pending CLI verification message(s) held for client 406B bycall recipient relay server 402.

Accordingly, a phone number included in incoming CLI may be verified bya client associated with a call recipient in many ways. For example,FIG. 5 shows a flowchart 500 of a method implemented by a clientassociated with a call recipient for verifying a phone number includedin incoming CLI in accordance with an example embodiment. In anembodiment, flowchart 500 may be implemented by system 600, as shown inFIG. 6. Accordingly, flowchart 500 will be described with reference FIG.6. FIG. 6 is a block diagram of a system 600 for verifying a phonenumber included in incoming CLI in accordance with an exampleembodiment. As shown in FIG. 6, system 600 comprises a call recipientrelay server 602 and a PNC application 614. Call recipient relay server602 and PNC application 614 are examples of call recipient relay server402 and PNC application 414, as described above with reference to FIG.4. Call recipient relay server 602 and PNC application 614 arecommunicatively coupled via a network, e.g., communications network 410,as described above with reference to FIG. 4. As also shown in FIG. 6,PNC application 614 comprises an extractor 604, a message analyzer 606,and a message retriever 608. Other structural and operationalembodiments will be apparent to persons skilled in the relevant art(s)based on the following discussion regarding flowchart 500 and system600.

As shown in FIG. 5, the method of flowchart 500 begins at step 502, inwhich a phone number is extracted from an incoming phone call. Forexample, with reference to FIG. 6, extractor 604 extracts a phone numberfrom CLI of an incoming phone call. Extractor 604 provides the phonenumber (shown as phone number 610) to message analyzer 606.

At step 504, a server is queried for a pending message that is intendedfor the call recipient. For example, with reference to FIG. 6, messageretriever 608 provides a request 620 to call recipient relay server 602for any pending message(s) intended for the call recipient. Request 620is an example of request 420, as described above with reference to FIG.4.

At step 506, a determination is made as to whether the extracted phonenumber matches a phone number included in the message. If adetermination is made that the extracted phone number does not match thephone number in the message (or if no message is pending or received),flow continues to step 508. Otherwise, flow continues to step 510. Forexample, with reference to FIG. 6, if a pending message for the callrecipient is available, call recipient relay server 602 may provide aresponse 622 comprising the message to message retriever 608. Messageretriever 608 provides the message (shown as message 612) to messageanalyzer 606. Response 622 is an example of response 422, as describedabove with reference to FIG. 4. Message analyzer 606 may analyze message612 to determine whether it is a verification message. If so, messageanalyzer 606 determines whether the verification message comprises thephone number of the caller from which it originates. For instance, thephone number may be included as part of message 612 itself or may beobtained via the signature of verification message 612. Message analyzer606 compares phone number 610 with the phone number included inverification message 612.

In the event that call recipient relay server 602 does not have anypending messages, call recipient relay server 602 may provide a responseindicating as such to message retriever 608. Alternatively, messageretriever 608 may determine that no such messages are available after apredetermined period of time expires since providing request 620 (i.e.,response 620 times out).

At step 508, a determination is made as to whether the incoming phonecall is from an illegitimate caller. Additional details regarding step508 are described below with respect to Subsection B.2.

At step 510, a first notification is caused to be outputted by theclient specifying that the incoming phone call is from a legitimatecaller. For example, with reference to FIG. 6, in response todetermining that phone number 610 matches the phone number included inverification message 612, message analyzer 606 causes PNC application614 to output a first notification. For instance, PNC application 614may cause a visual indicator (e.g., a checkmark) to be outputted on adisplay screen of a telephonic device (or PNC device, e.g., PNC device116, as shown in FIG. 1) associated with the call recipient's client. Inanother example, PNC application may cause a light emitting diode (LED)associated with the telephonic device or PNC device to activated (e.g.,a green LED) that indicates that the incoming CLI is accurate. In yetanother example, PNC application 614 may playback a particular sound orringtone via a speaker of the telephone device and/or PNC device.

2. Negative CLI Verification

FIG. 7 is a block diagram of a system 700 for performing negative CLIverification in accordance with an example embodiment. As shown in FIG.7, system 700 includes a call recipient relay server 702, a lookupservice 704, a client 706A, a client 706B, a telephonic device 716, anda certificate holder relay server 712. Clients 706A and 706B are each anexample of clients 106A-106C, as described above with reference toFIG. 1. Each of clients 706A and 706B comprise a PNC application 714,which is an example of PNC application 114, PNC application 214, PNCapplication 414, or PNC application 614 as respectively described abovewith reference to FIGS. 1, 2, 4, and 6. Lookup service 704 is an exampleof lookup service 104, lookup service 204, and lookup service 404, asrespectively described above with reference to FIGS. 1, 2, and 4. Callrecipient relay server 702 is an example of relay server 138, relayserver 238, call recipient relay server 402, and call recipient relayserver 602, as respectively described above with reference to FIGS. 1,2, 4, and 6. Certificate holder relay server 712 is an example of relayserver 138 and relay server 238, as respectively described above withreference to FIGS. 1 and 2. Client 706B, lookup service 704, callrecipient relay server 702, and certificate holder relay server 712 arecommunicatively coupled via communications network 710, which is anexample of communications network 110, as described above with referenceto FIG. 1. Client 706B is communicatively coupled to call recipientrelay server 702 via a persistent connection thereto.

In the example shown in FIG. 7, telephonic device 716 is associated witha caller that initiates a communication session (e.g., a phone call) viacommunications network 708 using a spoofed phone number (i.e., usinganother entity's phone number that is not owned by the caller).Communications network 708 is an example of communications network 108,as described above with reference to FIG. 1. Client 706B represents thecall recipient of the communication session. Client 706A represents theentity that had his number spoofed and that owns a digital certificatefor his phone number. Both clients 706A and 706B have been issued signeddigital certificates, client 406B has a statically-addressable URIallocated therefor via call recipient relay server 702, and client 606Ahas a statically-addressable URI allocated therefor via certificateholder relay server 712. Caller 716 has not obtained a signed digitalcertificate for the number he is spoofing. Instead, as described above,client 706A has obtained the digital certificate for the number beingspoofed by caller 716.

Negative CLI verification is used by a call recipient (i.e., client706B) to verify that incoming CLI is not correct (or inaccurate).Negative CLI verification may be initiated when PNC application 714 ofclient 706B determines that no verification message(s) are pending incall recipient relay server 702 or, if verification message(s) arepending, the phone number specified by such message(s) does not matchthe phone number extracted from the CLI of the telephonic communicationsession initiated by caller 716 (as described above with reference tosteps 506 and 508 of flowchart 500 of FIG. 5.

After determining that no verification message(s) are pending or if aphone number specified by verification message(s) do not match theextracted phone number, PNC application 714 of client 706B provides arequest 718 to lookup service 704 via communications network 710 todetermine whether the extracted phone number is associated with a signeddigital certificate. Request 718 specifies the extracted phone number.Lookup service 704 determines whether a signed digital certificate isassociated with such a number. If no digital certificate is associated,lookup service 704 may provide a response indicating as such andnegative CLI verification is not performed. In the event that a digitalcertificate is associated with such a number, lookup service 704provides a response 720 comprising the signed digital certificate to PNCapplication 714 of client 706B via communications network 710. Response720 may further include a statically-addressable URI of relay serverthat has been allocated for the certificate holder. In the example shownin FIG. 7, the extracted phone number is associated with client 706A,and the statically-addressable URI corresponds to certificate holderrelay server 712. In accordance with an embodiment, thestatically-addressable URI is included in the signed digital certificateprovided via response 720. Client 706B may optionally locally cache thedigital signed certificate and the URI, thereby enabling PNC application714 to retrieve the signed digital certificate and the URI withouthaving to query lookup service 704.

In accordance with an embodiment, PNC application 714 of client 706Bdetermines the URI of certificate holder relay server 712 providedthereto and provides a verification message 722 to certificate holderrelay server 712 based on the URI. Verification message 722 may besigned using the digital certificate of client 706B and may be entirelyor partially encrypted using the public key of client 706A (as obtainedvia the digital certificate retrieved from lookup service 704).Verification message 722 may include the signed digital certificate ofclient 706B and the statically-addressable URI corresponding to callrecipient relay server 702 and inquires whether certificate holder 706Ainitiated the telephonic communication session. Certificate holder relayserver 712 provides (or relays) verification message 722 to PNCapplication 714 of certificate holder 706A via communications network710. PNC application 714 of certificate holder 706A may decryptverification message 722 using the private key associated withcertificate holder 706A and determine the statically-addressable URIcorresponding to call recipient relay server 702 form verificationmessage 722. Alternatively, PNC application 714 may use the phone numberof call recipient 706B specified in the signed digital certificateincluded in verification message 722 and lookup the URI via lookupservice 704.

PNC application 714 provides a response 724 indicating whether or notthe telephonic communication session was initiated thereby. Response 724may be signed using the digital certificate of certificate holder 706Aand may be entirely or partially encrypted using the public key ofclient 706B (as determined from the received digital certificate ofclient 706B). Response 724 is provided to call recipient relay server702 via communications network 710 using the determined URI, and callrecipient relay server 702 provides (or relays) response 724 to PNCapplication 714 of call recipient 706B via communications network 710.PNC application 714 of client 706B decrypts the response using theprivate key associated with client 706B. If response 724 indicates thatcertificate holder 706A initiated the telephonic communication session,then PNC application 714 of client 706B determines that the phone numberextracted from the CLI is accurate. If response 724 indicates that thecertificate holder did not initiate the telephonic communicationsession, then PNC application of client 706B determines that theextracted phone number is inaccurate (i.e., the phone number wasspoofed).

In accordance with another embodiment, instead of certificate holderrelay server 712 relaying verification message 722 to PNC application714 of certificate holder 706A, certificate holder relay server 712determines whether client 706A is online and available. For instance, ifclient 706A has a persistent connection with certificate holder relayserver 712, certificate holder relay server 712 may determine thatclient 706 is online and available, and therefore, capable of providingpositive CLI-related verification messages (as described with referenceto Subsection B.1). Certificate holder relay server 712 provides aresponse to PNC application 714 of client 706B indicating whether or notcertificate holder 706A is online and available. If the responseindicates that certificate holder 706A is online and available, then PNCapplication 714 of client 706B infers that the extracted phone number isinaccurate, as no positive CLI-related verification messages wereprovided by certificate holder 706A. If the response indicates thatcertificate holder 706A is not online, PNC application 714 cannot make adetermination on the accuracy of the extracted phone number. That is,the telephonic communication session may have been initiated bycertificate holder 706A, however PNC application 714 cannot definitivelyascertain whether or not certificate holder 706A did so.

Responsive to determining that the incoming CLI is inaccurate, PNCapplication 704 of client 706B may cause a notification to be displayedand/or played back indicating the inaccurate CLI. For instance, PNCapplication 714 may cause an indicator (e.g., an “X”) to be displayed ona display screen of a telephonic device (or PNC device, e.g., PNC device116, as shown in FIG. 1) associated with client 706B. In anotherexample, PNC application 714 may cause a light emitting diode (LED)associated with the telephonic device or PNC device to activated (e.g.,a red LED) that indicates that the incoming CLI is inaccurate. In yetanother example, PNC application 714 may playback a particular sound orringtone via a speaker of the telephone device and/or PNC device thatindicates that the incoming CLI is inaccurate.

Accordingly, a phone number included in incoming CLI may be determinedto be inaccurate by a client associated with a call recipient in manyways. For example, FIG. 8 shows a flowchart 800 of a method implementedby a client associated with a call recipient for determining whether aphone number included in incoming CLI is inaccurate in accordance withan example embodiment. In an embodiment, flowchart 800 may beimplemented by system 900, as shown in FIG. 9. Accordingly, flowchart800 will be described with reference FIG. 9. FIG. 9 is a block diagramof a system 900 for determining whether a phone number included inincoming CLI is in inaccurate in accordance with an example embodiment.As shown in FIG. 9, system 900 comprises call recipient relay server 602and PNC application 614, as described above with reference to FIG. 6.System 900 further includes a lookup service 904, a certificate holderrelay server 914, and a certificate holder 906. Lookup service 904,certificate holder relay server 914, and certificate holder 906 areexamples of lookup service 704, certificate holder relay server 712, andcertificate holder 706A, as respectively described above with referenceto FIG. 7. Call recipient relay server 602, lookup service 904,certificate holder relay server 914, certificate holder 906, and PNCapplication 614 are communicatively coupled via a network, e.g.,communications network 710, as described above with reference to FIG. 7.As also shown in FIG. 6, PNC application 614 comprises extractor 604, asdescribed above with reference to FIG. 6. PNC application 614 furthercomprises a certificate retriever 902 and a message generator 908. Otherstructural and operational embodiments will be apparent to personsskilled in the relevant art(s) based on the following discussionregarding flowchart 800 and system 900.

As shown in FIG. 8, the method of flowchart 800 begins at step 802, inwhich a verification message is provided to a relay server based on auniform resource identifier, the verification message inquiring whetherthe incoming phone call originated from the extracted phone. Forexample, with reference to FIG. 9, message generator 908 generates andprovides a message 922 to certificate holder relay server 914 based on auniform resource identifier. Message 922 inquires whether certificateholder 906 initiated the incoming phone call. Message 922 is an exampleof message 722, as described above with reference to FIG. 7.

In accordance with one or more embodiments, the uniform resourceidentifier is included in a digital certificate associated with theextracted phone number. For example, with reference to FIG. 9,responsive to receiving an incoming phone call, extractor 604 extractsphone number 610 from the CLI and provides phone number 610 tocertificate retriever 602. Certificate retriever 902 provides a request918 comprising phone number 610 to lookup service 904. Request 918 is anexample of request 718, as described above with reference to FIG. 7.Lookup service 904 determines whether a digital certificate isassociated with the phone number. Responsive to determining that adigital certificate is associated with the phone number, lookup service904 provides a response 920 comprising the digital certificate tocertificate retriever 902. The digital certificate may include theuniform resource identifier. Alternatively, lookup service 904 maintainsthe uniform resource identifier separately from the digital certificate.Certificate retriever 902 provides the uniform resource identifier tomessage generator 908.

In accordance with one or more embodiments, the lookup service maintainsa plurality of digital certificates and a plurality of uniform resourceidentifiers that are associated with a plurality of different phonenumbers. For example, with reference to FIG. 9, lookup service 904maintains a plurality of digital certificates and a plurality of uniformresource identifiers that are associated with a plurality of differentphone numbers.

In accordance with one or more embodiments, the verification messagecomprises a digital signature from a signed digital certificate thatauthenticates the identity of the call recipient, and wherein thedigital certificate comprises a phone number of the call recipient. Forexample, with reference to FIG. 9, message 922 may comprise the digitalsignature from the signed digital certificate of the client associatedwith PNC application 614, along with the statically-addressable uniformresource identifier of call recipient relay server 602.

In accordance with one or more embodiments, the signed digitalcertificate further comprises a uniform resource identifier specifying arelay server that is associated with the call recipient. For example,with reference to FIG. 9, the signed digital certificate included inmessage 922 may include statically-addressable uniform resourceidentifier of call recipient relay server 602.

At step 804, responsive to receiving a response to the verificationmessage specifying that the incoming phone call originated from theextracted phone number, a first notification is caused to be outputtedby the client. For example, with reference to FIG. 9, certificate holderrelay server 914 may provide message 922 to PNC application (not shown)executing on the client of certificate holder 906. The PNC applicationmay respond to the message indicating that certificate holder 906 madethe incoming phone call. For example, the PNC application of certificateholder 906 may determine the statically-addressable URI included inmessage 922 and provide a response 924 to call recipient relay server602 specifying that certificate holder 906 initiated the incoming phonecall. Response 924 is an example of response 724, as described abovewith reference to FIG. 7. Call recipient relay server 602 providesmessage 924 to message generator 908. Message 924 may be encrypted usingthe public key of the call recipient (e.g, as generated by PNCapplication 614, as described above with reference to FIG. 2). Messagegenerator 908 may decrypt message 924 using the private key of the callrecipient (e.g., as generated by PNC application 614, as described abovewith reference to FIG. 2). PNC application 614 may cause the firstnotification to be outputted by the client associated therewith.

In accordance with one or more embodiment, the first notificationcomprises at least one of a visual indicator outputted via a displayscreen or an audio indicator outputted via a speaker associated with theclient associated with the client. For example, with reference to FIG.9, PNC application 614 may cause a visual indicator (e.g., a checkmark)to be outputted on a display screen of a telephonic device (or PNCdevice, e.g., PNC device 116, as shown in FIG. 1) associated with thecall recipient's client. In another example, PNC application 614 maycause a light emitting diode (LED) associated with the telephonic deviceor PNC device to activated (e.g., a green LED) that indicates that theincoming CLI is accurate. In yet another example, PNC application 614may playback a particular sound or ringtone via a speaker of thetelephone device and/or PNC device.

At step 806, responsive to receiving a response to the verificationmessage specifying that the incoming phone call did not originate fromthe extracted phone number, a second notification is caused to beoutputted by the client specifying that the incoming phone call is froman illegitimate caller. For example, the PNC application of certificateholder 906 may determine the statically-addressable URI included inmessage 922 and provide response 924 to call recipient relay server 602specifying that certificate holder 906 did not initiate the incomingphone call. Call recipient relay server 602 provides message 924 tomessage generator 908. PNC application 614 may cause the secondnotification to be displayed and/or played back indicating theinaccurate CLI. For instance, PNC application 614 may cause an indicator(e.g., an “X”) to be displayed on a display screen of a telephonicdevice (or PNC device, e.g., PNC device 116, as shown in FIG. 1)associated with PNC application 614. In another example, PNC application614 may cause a light emitting diode (LED) associated with thetelephonic device or PNC device to activated (e.g., a red LED) thatindicates that the incoming CLI is inaccurate. In yet another example,PNC application 614 may playback a particular sound or ringtone via aspeaker of the telephone device and/or PNC device that indicates thatthe incoming CLI is inaccurate.

III. Example Mobile and Stationary Device Embodiments

The systems and methods described above, including the phone numbercertification and verification techniques described in reference toFIGS. 1-9, may be implemented in hardware, or hardware combined with oneor both of software and/or firmware. For example, certificate authority102, lookup service 104, relay server 138, clients 106A-106C, telephones120A-120C, server 112, telephone 118, PNC device 116, PNC application114, certificate authority 202, lookup service 204, relay server 238,client 206, telephonic device 216, PNC application 214, key generator224, request sender 226, user interface 230, capabilities 228, clients406A and 406B, lookup service 404, call recipient relay server 402, PNCapplication 414, call recipient relay server 602, PNC application 614,extractor 604, message analyzer 606, message retriever 608, clients 706Aand 706B, telephonic device 716, call recipient relay server 702,certificate holder relay server 712, lookup service 704, PNC application714, certificate holder 906, certificate holder relay server 914, lookupservice 904, message generator 908, and/or certificate retriever 902,and/or each of the components described therein, and flowcharts 300,500, and/or 800 may be each implemented as computer programcode/instructions configured to be executed in one or more processorsand stored in a computer readable storage medium. Alternatively,certificate authority 102, lookup service 104, relay server 138, clients106A-106C, telephones 120A-120C, server 112, telephone 118, PNC device116, PNC application 114, certificate authority 202, lookup service 204,relay server 238, client 206, telephonic device 216, PNC application214, key generator 224, request sender 226, user interface 230,capabilities 228, clients 406A and 406B, lookup service 404, callrecipient relay server 402, PNC application 414, call recipient relayserver 602, PNC application 614, extractor 604, message analyzer 606,message retriever 608, clients 706A and 706B, telephonic device 716,call recipient relay server 702, certificate holder relay server 712,lookup service 704, PNC application 714, certificate holder 906,certificate holder relay server 914, lookup service 904, messagegenerator 908, and/or certificate retriever 902, and/or each of thecomponents described therein, and flowcharts 300, 500, and/or 800 may beimplemented as hardware logic/electrical circuitry. In an embodiment,certificate authority 102, lookup service 104, relay server 138, clients106A-106C, telephones 120A-120C, server 112, telephone 118, PNC device116, PNC application 114, certificate authority 202, lookup service 204,relay server 238, client 206, telephonic device 216, PNC application214, key generator 224, request sender 226, user interface 230,capabilities 228, clients 406A and 406B, lookup service 404, callrecipient relay server 402, PNC application 414, call recipient relayserver 602, PNC application 614, extractor 604, message analyzer 606,message retriever 608, clients 706A and 706B, telephonic device 716,call recipient relay server 702, certificate holder relay server 712,lookup service 704, PNC application 714, certificate holder 906,certificate holder relay server 914, lookup service 904, messagegenerator 908, and/or certificate retriever 902, and/or each of thecomponents described therein, and flowcharts 300, 500, and/or 800 may beimplemented in one or more SoCs (system on chip). An SoC may include anintegrated circuit chip that includes one or more of a processor (e.g.,a central processing unit (CPU), microcontroller, microprocessor,digital signal processor (DSP), etc.), memory, one or more communicationinterfaces, and/or further circuits, and may optionally execute receivedprogram code and/or include embedded firmware to perform functions.

FIG. 10 shows a block diagram of an exemplary mobile device 1000including a variety of optional hardware and software components, showngenerally as components 1002. Any number and combination of thefeatures/elements of the systems and methods described above (e.g.,client 106C, PNC application 114, client 206, telephonic device 216, PNCapplication 214, key generator 224, request sender 226, user interface230, capabilities 228, clients 406A and 406B, PNC application 414, PNCapplication 614, extractor 604, message analyzer 606, message retriever608, clients 706A and 706B, telephonic device 716, PNC application 714,message generator 908, and/or certificate retriever 902, and/or each ofthe components described therein, and flowcharts 500 and/or 800) may beimplemented as components 1002 included in a mobile device embodiment,as well as additional and/or alternative features/elements, as would beknown to persons skilled in the relevant art(s). It is noted that any ofcomponents 1002 can communicate with any other of components 1002,although not all connections are shown, for ease of illustration. Mobiledevice 1000 can be any of a variety of mobile devices described ormentioned elsewhere herein or otherwise known (e.g., cell phone,smartphone, handheld computer, Personal Digital Assistant (PDA), etc.)and can allow wireless two-way communications with one or more mobiledevices over one or more communications networks 1004, such as acellular or satellite network, or with a local area or wide areanetwork.

The illustrated mobile device 1000 can include a controller or processorreferred to as processor circuit 1010 for performing such tasks assignal coding, image processing, data processing, input/outputprocessing, power control, and/or other functions. Processor circuit1010 is an electrical and/or optical circuit implemented in one or morephysical hardware electrical circuit device elements and/or integratedcircuit devices (semiconductor material chips or dies) as a centralprocessing unit (CPU), a microcontroller, a microprocessor, and/or otherphysical hardware processor circuit. Processor circuit 1010 may executeprogram code stored in a computer readable medium, such as program codeof one or more applications 1014, operating system 1012, any programcode stored in memory 1020, etc. Operating system 1012 can control theallocation and usage of the components 1002 and support for one or moreapplication programs 1014 (a.k.a. applications, “apps”, etc.).Application programs 1014 can include common mobile computingapplications (e.g., email applications, calendars, contact managers, webbrowsers, messaging applications) and any other computing applications(e.g., word processing applications, mapping applications, media playerapplications).

As illustrated, mobile device 1000 can include memory 1020. Memory 1020can include non-removable memory 1022 and/or removable memory 1024. Thenon-removable memory 1022 can include RAM, ROM, flash memory, a harddisk, or other well-known memory storage technologies. The removablememory 1024 can include flash memory or a Subscriber Identity Module(SIM) card, which is well known in GSM communication systems, or otherwell-known memory storage technologies, such as “smart cards.” Thememory 1020 can be used for storing data and/or code for runningoperating system 1012 and applications 1014. Example data can includeweb pages, text, images, sound files, video data, or other data sets tobe sent to and/or received from one or more network servers or otherdevices via one or more wired or wireless networks. Memory 1020 can beused to store a subscriber identifier, such as an International MobileSubscriber Identity (IMSI), and an equipment identifier, such as anInternational Mobile Equipment Identifier (IMEI). Such identifiers canbe transmitted to a network server to identify users and equipment.

A number of programs may be stored in memory 1020. These programsinclude operating system 1012, one or more application programs 1014,and other program modules and program data. Examples of such applicationprograms or program modules may include, for example, computer programlogic (e.g., computer program code or instructions) for implementing thesystems and methods described above, including the embodiments describedin reference to FIGS. 1-9.

Mobile device 1000 can support one or more input devices 1030, such as atouch screen 1032, microphone 1034, camera 1036, physical keyboard 1038and/or trackball 1040 and one or more output devices 1050, such as aspeaker 1052 and a display 1054.

Other possible output devices (not shown) can include piezoelectric orother haptic output devices. Some devices can serve more than oneinput/output function. For example, touch screen 1032 and display 1054can be combined in a single input/output device. The input devices 1030can include a Natural User Interface (NUI).

Wireless modem(s) 1060 can be coupled to antenna(s) (not shown) and cansupport two-way communications between processor circuit 1010 andexternal devices, as is well understood in the art. The modem(s) 1060are shown generically and can include a cellular modem 1066 forcommunicating with the mobile communication network 1004 and/or otherradio-based modems (e.g., Bluetooth 1064 and/or Wi-Fi 1062). Cellularmodem 1066 may be configured to enable phone calls (and optionallytransmit data) according to any suitable communication standard ortechnology, such as GSM, 3G, 4G, 5G, etc. At least one of the wirelessmodem(s) 1060 is typically configured for communication with one or morecellular networks, such as a GSM network for data and voicecommunications within a single cellular network, between cellularnetworks, or between the mobile device and a public switched telephonenetwork (PSTN).

Mobile device 1000 can further include at least one input/output port1080, a power supply 1082, a satellite navigation system receiver 1084,such as a Global Positioning System (GPS) receiver, an accelerometer1086, and/or a physical connector 1090, which can be a USB port, IEEE1394 (FireWire) port, and/or RS-232 port. The illustrated components1002 are not required or all-inclusive, as any components can be notpresent and other components can be additionally present as would berecognized by one skilled in the art.

Furthermore, FIG. 11 depicts an exemplary implementation of a computingdevice 1100 in which embodiments may be implemented, includingcertificate authority 102, lookup service 104, relay server 138, clients106A-106C, telephones 120A-120C, server 112, telephone 118, PNC device116, PNC application 114, certificate authority 202, lookup service 204,relay server 238, client 206, telephonic device 216, PNC application214, key generator 224, request sender 226, user interface 230,capabilities 228, clients 406A and 406B, lookup service 404, callrecipient relay server 402, PNC application 414, call recipient relayserver 602, PNC application 614, extractor 604, message analyzer 606,message retriever 608, clients 706A and 706B, telephonic device 716,call recipient relay server 702, certificate holder relay server 712,lookup service 704, PNC application 714, certificate holder 906,certificate holder relay server 914, lookup service 904, messagegenerator 908, and/or certificate retriever 902, and/or each of thecomponents described therein, and flowcharts 300, 500, and/or 800. Thedescription of computing device 1100 provided herein is provided forpurposes of illustration, and is not intended to be limiting.Embodiments may be implemented in further types of computer systems, aswould be known to persons skilled in the relevant art(s).

As shown in FIG. 11, computing device 1100 includes one or moreprocessors, referred to as processor circuit 1102, a system memory 1104,and a bus 1106 that couples various system components including systemmemory 1104 to processor circuit 1102. Processor circuit 1102 is anelectrical and/or optical circuit implemented in one or more physicalhardware electrical circuit device elements and/or integrated circuitdevices (semiconductor material chips or dies) as a central processingunit (CPU), a microcontroller, a microprocessor, and/or other physicalhardware processor circuit. Processor circuit 1102 may execute programcode stored in a computer readable medium, such as program code ofoperating system 1130, application programs 1132, other programs 1134,etc. Bus 1106 represents one or more of any of several types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. System memory 1104 includes readonly memory (ROM) 1108 and random access memory (RAM) 1110. A basicinput/output system 1112 (BIOS) is stored in ROM 1108.

Computing device 1100 also has one or more of the following drives: ahard disk drive 1114 for reading from and writing to a hard disk, amagnetic disk drive 1116 for reading from or writing to a removablemagnetic disk 1118, and an optical disk drive 1120 for reading from orwriting to a removable optical disk 1122 such as a CD ROM, DVD ROM, orother optical media. Hard disk drive 1114, magnetic disk drive 1116, andoptical disk drive 1120 are connected to bus 1106 by a hard disk driveinterface 1124, a magnetic disk drive interface 1126, and an opticaldrive interface 1128, respectively. The drives and their associatedcomputer-readable media provide nonvolatile storage of computer-readableinstructions, data structures, program modules and other data for thecomputer. Although a hard disk, a removable magnetic disk and aremovable optical disk are described, other types of hardware-basedcomputer-readable storage media can be used to store data, such as flashmemory cards, digital video disks, RAMs, ROMs, and other hardwarestorage media.

A number of program modules may be stored on the hard disk, magneticdisk, optical disk, ROM, or RAM. These programs include operating system1130, one or more application programs 1132, other programs 1134, andprogram data 1136. Application programs 1132 or other programs 1134 mayinclude, for example, computer program logic (e.g., computer programcode or instructions) for implementing the systems and methods describedabove, including the embodiments described above with reference to FIGS.1-9.

A user may enter commands and information into the computing device 1100through input devices such as keyboard 1138 and pointing device 1140.Other input devices (not shown) may include a microphone, joystick, gamepad, satellite dish, scanner, a touch screen and/or touch pad, a voicerecognition system to receive voice input, a gesture recognition systemto receive gesture input, or the like. These and other input devices areoften connected to processor circuit 1102 through a serial portinterface 1142 that is coupled to bus 1106, but may be connected byother interfaces, such as a parallel port, game port, or a universalserial bus (USB).

A display screen 1144 is also connected to bus 1106 via an interface,such as a video adapter 1146. Display screen 1144 may be external to, orincorporated in computing device 1100. Display screen 1144 may displayinformation, as well as being a user interface for receiving usercommands and/or other information (e.g., by touch, finger gestures,virtual keyboard, etc.). In addition to display screen 1144, computingdevice 1100 may include other peripheral output devices (not shown) suchas speakers and printers.

Computing device 1100 is connected to a network 1148 (e.g., theInternet) through an adaptor or network interface 1150, a modem 1152, orother means for establishing communications over the network. Modem1152, which may be internal or external, may be connected to bus 1106via serial port interface 1142, as shown in FIG. 11, or may be connectedto bus 1106 using another interface type, including a parallelinterface.

As used herein, the terms “computer program medium,” “computer-readablemedium,” and “computer-readable storage medium” are used to generallyrefer to physical hardware media such as the hard disk associated withhard disk drive 1114, removable magnetic disk 1118, removable opticaldisk 1122, other physical hardware media such as RAMs, ROMs, flashmemory cards, digital video disks, zip disks, MEMs, nanotechnology-basedstorage devices, solid state drives, and further types ofphysical/tangible hardware storage media (including system memory 1104of FIG. 11). Such computer-readable storage media are distinguished fromand non-overlapping with communication media (do not includecommunication media). Communication media typically embodiescomputer-readable instructions, data structures, program modules orother data in a modulated data signal such as a carrier wave. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wireless media such as acoustic, RF, infrared and otherwireless media, as well as wired media. Embodiments are also directed tosuch communication media.

As noted above, computer programs and modules (including applicationprograms 1132 and other programs 1134) may be stored on the hard disk,magnetic disk, optical disk, ROM, RAM, or other hardware storage medium.Such computer programs may also be received via network interface 1150,serial port interface 1152, or any other interface type. Such computerprograms, when executed or loaded by an application, enable computingdevice 1100 to implement features of embodiments discussed herein.Accordingly, such computer programs represent controllers of thecomputing device 1100.

Embodiments are also directed to computer program products comprisingcomputer code or instructions stored on any computer-readable medium.Such computer program products include hard disk drives, optical diskdrives, memory device packages, portable memory sticks, memory cards,and other types of physical storage hardware.

IV. Additional Example Embodiments

A method in a server for associating a digital certificate with a phonenumber associated with a client is described herein. The methodcomprises: receiving a request from the client for a signed digitalcertificate, the request specifying the phone number associated with theclient; determining a phone number verification process from a pluralityof phone number verification processes based on the request; providing,to the client, a phone number verification request in accordance withthe determined phone number verification process, the phone numberverification request specifying a first verification code; responsive toreceiving a second verification code, determining whether the secondverification code matches the first verification code; and in responseto determining that the second verification code matches the firstverification code, providing the signed digital certificate to theclient.

In one embodiment of the foregoing method, the method further comprisesin response to determining that the second verification code does notmatch the first verification code or in response to determining that nosecond verification code is received, denying the request for the signeddigital certificate.

In one embodiment of the foregoing method, the method further comprises:in response to determining that the second verification code matches thefirst verification code: generating and signing the digital certificate;and providing the signed, digital certificate to a lookup service thatenables the signed, digital certificate to be searchable and retrievableby a plurality of requesting entities.

In one embodiment of the foregoing method, the signed, digitalcertificate comprises at least one of the phone number associated withthe client or a uniform resource identifier associated with a relayserver.

In one embodiment of the foregoing method, the plurality of differentphone number verification processes comprises a short message service(SMS)-based verification process, and said providing the phone numberverification request comprises: providing, to the client, the phonenumber verification request as an SMS-based text message comprising thefirst verification code via a first communication channel; and receivingthe second verification code via a second communication channel that isdifferent than the first communication channel.

In one embodiment of the foregoing method, the plurality of differentphone number verification processes comprises an audio code-basedverification process, and said providing the phone number verificationrequest comprises: initiating, via a first communication channel, atelephonic communication session with the client; responsive to thetelephonic communication session being accepted, providing the firstverification code as an auditory code via the telephonic communicationsession; and receiving the second verification code via a secondcommunication channel that is different than the first communicationchannel.

In one embodiment of the foregoing method, the auditory code is inaccordance with a dual-tone multi-frequency form.

In one embodiment of the foregoing method, the request further specifiesthe phone number verification process.

A method implemented by a client associated with a call recipient isalso described herein. The method comprises: extracting a phone numberfrom an incoming phone call; querying a server for a pending messagethat is intended for the call recipient; responsive to receiving thepending message, determining whether the extracted phone number matchesa phone number included in the message; in response to determining thatthe extracted phone number matches the phone number included in themessage, causing a first notification to be outputted by the clientspecifying that the incoming phone call is from a legitimate caller; andresponsive to receiving no message or in response to determining thatthe extracted phone number does not match the phone number included inthe message, determining whether the incoming phone call is from anillegitimate caller.

In one embodiment of the foregoing method, said determining whether theincoming phone call is from an illegitimate caller comprises: providinga verification message to a relay server based on a uniform resourceidentifier specifying the relay server, the verification messageinquiring whether the incoming phone call originated from the extractedphone number; responsive to receiving a response to the verificationmessage specifying that the incoming phone call originated from theextracted phone number, causing the first notification to be outputtedby the client; and responsive to receiving a response to theverification message specifying that the incoming phone call did notoriginate from the extracted phone number, causing a second notificationto be outputted by the client specifying that the incoming phone call isfrom an illegitimate caller.

In one embodiment of the foregoing method, the uniform resourceidentifier is included in a digital certificate associated with theextracted phone number.

In one embodiment of the foregoing method, the verification messagecomprises a digital signature that authenticates the identity of thecall recipient, and the signed digital certificate comprises a phonenumber of the call recipient.

In one embodiment of the foregoing method, the signed digitalcertificate further comprises a uniform resource identifier specifying arelay server that is associated with the call recipient.

In one embodiment of the foregoing method, the response to theverification message is received from the relay server associated withthe call recipient.

In one embodiment of the foregoing method, at least one of the firstnotification or the second notification comprises at least one of: avisual indicator outputted via a display screen associated with theclient; or an audio indicator outputted via a speaker associated withthe client.

A computing device is further described herein. The computing deviceincludes:

at least one processor circuit; and at least one memory that storesprogram code configured to perform a method when executed by the atleast one processor circuit. The method includes: extracting a phonenumber from an incoming phone call; querying a server for a pendingmessage that is intended for a call recipient associated with thecomputing device; responsive to receiving the pending message,determining whether the extracted phone number matches a phone numberincluded in the message; in response to determining that the extractedphone number matches the phone number included in the message, causing afirst notification to be outputted by the computing device specifyingthat the incoming phone call is from a legitimate caller; and responsiveto receiving no message or in response to determining that the extractedphone number does not match the phone number included in the message,determining whether the incoming phone call is from an illegitimatecaller.

In one embodiment of the foregoing computing device, said determiningwhether the incoming phone call is from an illegitimate callercomprises: providing a verification message to a relay server based on auniform resource identifier specifying the relay server, theverification message inquiring whether the incoming phone calloriginated from the extracted phone number; responsive to receiving aresponse to the verification message specifying that the incoming phonecall originated from the extracted phone number, causing the firstnotification to be outputted by the computing device; and responsive toreceiving a response to the verification message specifying that theincoming phone call did not originate from the extracted phone number,causing a second notification to be outputted by the computing devicespecifying that the incoming phone call is from an illegitimate caller.

In one embodiment of the foregoing computing device, the uniformresource identifier is included in a digital certificate associated withthe extracted phone number.

In one embodiment of the foregoing computing device, the verificationmessage comprises a digital signature that authenticates the identity ofthe call recipient, and the signed digital certificate comprises a phonenumber of the call recipient.

In one embodiment of the foregoing computing device, the signed digitalcertificate further comprises a uniform resource identifier specifying arelay server that is associated with the call recipient.

V. Conclusion

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. It will be understood by those skilled in the relevantart(s) that various changes in form and details may be made thereinwithout departing from the spirit and scope of the described embodimentsas defined in the appended claims. Accordingly, the breadth and scope ofthe present embodiments should not be limited by any of theabove-described exemplary embodiments, but should be defined only inaccordance with the following claims and their equivalents.

What is claimed is:
 1. A method in a server for associating a digitalcertificate with a phone number associated with a client, comprising:receiving a request from the client for a signed digital certificate,the request specifying the phone number associated with the client;determining a phone number verification process from a plurality ofphone number verification processes based on the request; providing, tothe client, a phone number verification request in accordance with thedetermined phone number verification process, the phone numberverification request specifying a first verification code; responsive toreceiving a second verification code, determining whether the secondverification code matches the first verification code; and in responseto determining that the second verification code matches the firstverification code, providing the signed digital certificate to theclient.
 2. The method of claim 1, further comprising: in response todetermining that the second verification code does not match the firstverification code or in response to determining that no secondverification code is received, denying the request for the signeddigital certificate.
 3. The method of claim 1, further comprising: inresponse to determining that the second verification code matches thefirst verification code: generating and signing the digital certificate;and providing the signed, digital certificate to a lookup service thatenables the signed, digital certificate to be searchable and retrievableby a plurality of requesting entities.
 4. The method of claim 3, whereinthe signed, digital certificate comprises at least one of the phonenumber associated with the client or a uniform resource identifierassociated with a relay server.
 5. The method of claim 1, wherein theplurality of different phone number verification processes comprises ashort message service (SMS)-based verification process, and wherein saidproviding the phone number verification request comprises: providing, tothe client, the phone number verification request as an SMS-based textmessage comprising the first verification code via a first communicationchannel; and receiving the second verification code via a secondcommunication channel that is different than the first communicationchannel.
 6. The method of claim 1, wherein the plurality of differentphone number verification processes comprises an audio code-basedverification process, and wherein said providing the phone numberverification request comprises: initiating, via a first communicationchannel, a telephonic communication session with the client; responsiveto the telephonic communication session being accepted, providing thefirst verification code as an auditory code via the telephoniccommunication session; and receiving the second verification code via asecond communication channel that is different than the firstcommunication channel.
 7. The method of claim 6, wherein the requestfurther specifies the phone number verification process.
 8. A methodimplemented by a client associated with a call recipient, comprising:extracting a phone number from an incoming phone call; querying a serverfor a pending message that is intended for the call recipient;responsive to receiving the pending message, determining whether theextracted phone number matches a phone number included in the message;in response to determining that the extracted phone number matches thephone number included in the message, causing a first notification to beoutputted by the client specifying that the incoming phone call is froma legitimate caller; and responsive to receiving no message or inresponse to determining that the extracted phone number does not matchthe phone number included in the message, determining whether theincoming phone call is from an illegitimate caller.
 9. The method ofclaim 8, wherein said determining whether the incoming phone call isfrom an illegitimate caller comprises: providing a verification messageto a relay server based on a uniform resource identifier specifying therelay server, the verification message inquiring whether the incomingphone call originated from the extracted phone number; responsive toreceiving a response to the verification message specifying that theincoming phone call originated from the extracted phone number, causingthe first notification to be outputted by the client; and responsive toreceiving a response to the verification message specifying that theincoming phone call did not originate from the extracted phone number,causing a second notification to be outputted by the client specifyingthat the incoming phone call is from an illegitimate caller.
 10. Themethod of claim 9, wherein the uniform resource identifier is includedin a digital certificate associated with the extracted phone number. 11.The method of claim 9, wherein the verification message comprises adigital signature that authenticates the identity of the call recipient,and wherein the signed digital certificate comprises a phone number ofthe call recipient.
 12. The method of claim 11, wherein the signeddigital certificate further comprises a uniform resource identifierspecifying a relay server that is associated with the call recipient.13. The method of claim 11, wherein the response to the verificationmessage is received from the relay server associated with the callrecipient.
 14. The method of claim 9, wherein at least one of the firstnotification or the second notification comprises at least one of: avisual indicator outputted via a display screen associated with theclient; or an audio indicator outputted via a speaker associated withthe client.
 15. The method of claim 10, wherein the digital certificateis retrieved from a lookup service that maintains a plurality of digitalcertificates and a plurality of uniform resource identifiers that areassociated with a plurality of different phone numbers.
 16. A computingdevice, comprising: at least one processor circuit; and at least onememory that stores program code configured to perform a method whenexecuted by the at least one processor circuit, the method comprising:extracting a phone number from an incoming phone call; querying a serverfor a pending message that is intended for a call recipient associatedwith the computing device; responsive to receiving the pending message,determining whether the extracted phone number matches a phone numberincluded in the message; in response to determining that the extractedphone number matches the phone number included in the message, causing afirst notification to be outputted by the computing device specifyingthat the incoming phone call is from a legitimate caller; and responsiveto receiving no message or in response to determining that the extractedphone number does not match the phone number included in the message,determining whether the incoming phone call is from an illegitimatecaller.
 17. The computing device of claim 16, wherein said determiningwhether the incoming phone call is from an illegitimate callercomprises: providing a verification message to a relay server based on auniform resource identifier specifying the relay server, theverification message inquiring whether the incoming phone calloriginated from the extracted phone number; responsive to receiving aresponse to the verification message specifying that the incoming phonecall originated from the extracted phone number, causing the firstnotification to be outputted by the computing device; and responsive toreceiving a response to the verification message specifying that theincoming phone call did not originate from the extracted phone number,causing a second notification to be outputted by the computing devicespecifying that the incoming phone call is from an illegitimate caller.18. The computing device of claim 17, wherein the uniform resourceidentifier is included in a digital certificate associated with theextracted phone number.
 19. The computing device of claim 17, whereinthe verification message comprises a digital signature thatauthenticates the identity of the call recipient, and wherein the signeddigital certificate comprises a phone number of the call recipient. 20.The computing device of claim 19, wherein the signed digital certificatefurther comprises a uniform resource identifier specifying a relayserver that is associated with the call recipient.